if it's a location, it's an URL, right?

I think this is in there to make sure clients don't make assumptions that the authorization server URL might not contain a query string. Also note that just below this there's a limit that the URL can't contain a fragment, so I think it's worth pointing out still.

this is in there to make sure clients don't make assumptions that the authorization server URL might not contain a query string

I don't understand how this is related to the query string. IIUC, both URI and URL can have a query component:

• URI query
• URL query

Yes, but without an explicit mention, I suspect a lot of people would assume the URL would not contain a query string, especially because it's pretty uncommon for it to do so in practice.

without an explicit mention

we explicitly mention the query component in the lines below - that are not removed - so people are told that URLs have query component.

@aaronpk

this section applies to the authorization endpoints, not to all the authorization server, right?

I suppose it wouldn't refer to the token endpoint, only to endpoints that a user might interact with.

So is it correct in line 992 to use "authorization endpoint" ?

I don't think adding "untrusted parties" here is beneficial

Can we say that "it MUST NOT forward these credentials" never, in any case?

That gets a bit tricky, because it might need to "forward" the credentials to itself, and then what are the boundaries of its "self" becomes challenging to describe concisely. I think that's the reason the original text said "accidentally".

@aaronpk "MUST avoid to accidentally" sounds like SHOULD CONSIDER. IMHO does not provide any interoperability guidance because it is related to an unintended behavior.

In general, I'd track down RFC6919-sounding statements in this document and address them before AD / IESG review will ask us to do it.

I don't think adding "untrusted parties" here is beneficial

imho helps avoiding the fallacies of "accidentally", since it suggests the AS to internally define a trusted boundary for credentials.

@aaronpk I reworded it removing normative language. This is because we cannot forbid to accidentally do something ;) instead it is better to suggest how to mitigate the risk.